home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_5_11.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
80KB
|
3,574 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.sp 2P
.LP
\fBRecommendation\ X.228\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBRELIABLE TRANSFER:\fR \fBPROTOCOL SPECIFICATION\fR
.FS
Recommendation\ X.228 and ISO 9066\(hy2 [Information processing systems
\(em Text
Communication \(em Reliable Transfer Part\ 2: Protocol Specification] were
developed in close collaboration and are technically aligned.
.FE
.EF '% Fascicle\ VIII.5\ \(em\ Rec.\ X.228''
.OF '''Fascicle\ VIII.5\ \(em\ Rec.\ X.228 %'
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
The CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that Recommendation X.200 defines the Basic Reference Model of Open Systems
Interconnection (OSI) for CCITT applications;
.PP
(b)
that Recommendation X.210 defines the service conventions for describing
the services of the OSI reference model;
.PP
(c)
that Recommendation X.216 defines the Presentation Layer
service;
.PP
(d)
that Recommendation X.217 defines the Association Control service;
.PP
(e)
that Recommendation X.218 defines the Reliable Transfer
service;
.PP
(f
)
that there is a need for common Reliable Transfer
support for various applications;
.sp 1P
.LP
\fIunanimously declares\fR
.sp 9p
.RT
.PP
that this Recommendation defines the Reliable Transfer protocol of Open
Systems Interconnection for CCITT Applications as given in the Scope and
Field of Application.
.sp 1P
.ce 1000
CONTENTS
.ce 0
.sp 1P
.sp 2P
.LP
0
\fIIntroduction\fR
.sp 1P
.RT
.sp 1P
.LP
1
\fIScope and Field of Application\fR
.sp 9p
.RT
.sp 1P
.LP
2
\fIReferences\fR
.sp 9p
.RT
.sp 1P
.LP
3
\fIDefinitions\fR
.sp 9p
.RT
.sp 1P
.LP
4
\fIAbbreviations\fR
.sp 9p
.RT
.sp 1P
.LP
5
\fIConventions\fR
.sp 9p
.RT
.sp 1P
.LP
6
\fIOverview of the Protocol\fR
.sp 9p
.RT
.sp 1P
.LP
7
\fIElements of Procedure\fR
.sp 9p
.RT
.sp 1P
.LP
8
\fIMapping to Used Services\fR
.sp 9p
.RT
.sp 1P
.LP
9
\fIAbstract Syntax Definition of APDUs\fR
.sp 9p
.RT
.sp 1P
.LP
10
\fIConformance\fR
.sp 9p
.RT
.sp 1P
.LP
\fIAnnex A\fR \(em
State Transition Tables
.sp 9p
.RT
.sp 1P
.LP
\fIAnnex B\fR \(em
Differences between this Recommendation and\fR Recommendation\ X.410\
\(em\ 1984
.sp 9p
.RT
.sp 1P
.LP
\fIAnnex C\fR \(em
Summary of Assigned Object Identifier
Values
.bp
.sp 9p
.RT
.sp 2P
.LP
\fB0\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation specifies the protocol for the services
provided by an application\(hyservice\(hyelement\ \(em\ the Reliable Transfer
Service
Element (RTSE)\ \(em\ to provide for the Reliable Transfer of Application
Protocol Data Units (APDUs) between open systems. This Recommendation is
one of a set of Recommendations specifying the protocols for sets of
application\(hyservice\(hyelements commonly used by a number of applications.
.PP
Reliable Transfer provides an application\(hyindependent mechanism to
recover from communication and end\(hysystem failure minimizing the amount of
retransmission.
.PP
This Recommendation is technically aligned with ISO 9066\(hy2.
.RT
.sp 2P
.LP
\fB1\fR \fBScope and Field of Application\fR
.sp 1P
.RT
.PP
This Recommendation specifies the protocol (abstract syntax) and
procedures for the Reliable Transfer Service Element services (Recommendation
X.218). The RTSE services are provided in conjunction with the Association
Control Service Element (ACSE) services (Recommendation X.217) and the ACSE
protocol (Recommendation X.227), and the presentation\(hyservice (Recommendation
X.216).
.PP
The RTSE procedures are defined in terms of:
.RT
.LP
a)
the interactions between peer RTSE protocol machines
through the use of ACSE and the presentation\(hyservice.
.LP
b)
the interactions between the RTSE protocol machine and its service\(hyuser.
.PP
This Recommendation specifies conformance requirements for systems implementing
these procedures.
.sp 2P
.LP
\fB2\fR \fBReferences\fR
.sp 1P
.RT
.sp 1P
.LP
Recommendation X.200\ \(em
Reference Model of Open Systems Interconnection
for CCITT Applications (See also ISO\ 7498)
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.208\ \(em
Specification of abstract syntax notation (See
also ISO\ 8824).
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.209\ \(em
Specification of Basic Encoding Rules for the
abstract syntax notation (See also ISO\ 8825).
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.210\ \(em
Open Systems Interconnection Layer Service
Definition Conventions (See also ISO/TR\ 8509).
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.216\ \(em
Presentation Service Definition for Open Systems Interconnection for
CCITT Applications (See also ISO\ 8822).
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.217\ \(em
Association Control Service Definition for CCITT Applications (See also
ISO\ 8649).
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.218\ \(em
Reliable Transfer: Model and Service Definition
(See also ISO 9066\(hy1)
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.219\ \(em
Remote Operations: Model, Notation and Service
Definition (See also ISO\ 9072\(hy1)
.sp 9p
.RT
.sp 1P
.LP
Recommendation X.227\ \(em
Association Control Protocol Specification for
CCITT Applications (See also ISO\ 8650).
.sp 9p
.RT
.sp 2P
.LP
\fB3\fR \fBDefinitions\fR
.sp 1P
.RT
.sp 1P
.LP
3.1
\fIReference Model Definitions\fR
.sp 9p
.RT
.PP
This Recommendation is based on the concepts developed in
Recommendation X. 200 and makes use of the following terms defined in
it:
.RT
.LP
a)
Application Layer;
.LP
b)
application\(hyprocess;
.LP
c)
application\(hyentity;
.bp
.LP
d)
application\(hyservice\(hyelement;
.LP
e)
application\(hyprotocol\(hydata\(hyunit;
.LP
f
)
application\(hyprotocol\(hycontrol\(hyinformation;
.LP
g)
presentation\(hyservice;
.LP
h)
presentation\(hyconnection;
.LP
i)
session\(hyservice;
.LP
j
)
session\(hyconnection; and
.LP
k)
user\(hyelement
.LP
l)
two\(hyway\(hyalternate interaction
.LP
m)
transfer syntax.
.sp 1P
.LP
3.2
\fIService Conventions Definitions\fR
.sp 9p
.RT
.PP
This Recommendation makes use of the following terms defined in
Recommendation\ X.210:
.RT
.LP
a)
service\(hyprovider;
.LP
b)
service\(hyuser;
.LP
c)
confirmed service;
.LP
d)
non\(hyconfirmed service;
.LP
e)
provider\(hyinitiated service;
.LP
f
)
primitive;
.LP
g)
request (primitive);
.LP
h)
indication (primitive);
.LP
i)
response (primitive); and
.LP
j
)
confirm (primitive).
.sp 1P
.LP
3.3
\fIPresentation Service Definitions\fR
.sp 9p
.RT
.PP
This Recommendation makes use of the following terms defined in
Recommendation\ X.216:
.RT
.LP
a)
abstract syntax;
.LP
b)
abstract syntax name;
.LP
c)
presentation context;
.LP
d)
default context.
.sp 1P
.LP
3.4
\fIAssociation Control Definitions\fR
.sp 9p
.RT
.PP
This Recommendation makes use of the following terms defined in
Recommendation\ X.217:
.RT
.LP
a)
application\(hyassociation; association;
.LP
b)
application context;
.LP
c)
Association Control Service Element; and
.LP
d)
X.410\(hy1984 mode.
.sp 1P
.LP
3.5
\fIRTSE Service Definitions\fR
.sp 9p
.RT
.PP
This Recommendation makes use of the following terms defined in
Recommendation\ X.218:
.RT
.LP
a)
association\(hyinitiating\(hyapplication\(hyentity; association\(hyinitiator;
.LP
b)
association\(hyresponding\(hyapplication\(hyentity; association\(hyresponder;
.LP
c)
sending\(hyapplication\(hyentity; sender;
.LP
d)
receiving\(hyapplication\(hyentity; receiver;
.LP
e)
requestor;
.LP
f
)
acceptor;
.LP
g)
Reliable Transfer Service Element;
.LP
h)
RTSE\(hyuser;
.LP
i)
RTSE\(hyprovider;
.LP
j
)
ACSE\(hyprovider;
.bp
.LP
k)
monologue interaction;
.LP
l)
syntax\(hymatching\(hyservices;
.LP
m)
Reliable Transfer;
.LP
n)
X.410\(hy1984 mode; and
.LP
o)
normal mode.
.sp 1P
.LP
3.6
\fIReliable Transfer Protocol Specification Definitions\fR
.sp 9p
.RT
.PP
For the purpose of this Recommendation the following definitions
apply:
.RT
.sp 1P
.LP
3.6.1
\fBreliable\(hytransfer\(hyprotocol\(hymachine\fR :
.sp 9p
.RT
.PP
The protocol machine for the Reliable Transfer Service Element
specified in this Recommendation.
.RT
.sp 1P
.LP
3.6.2
\fBrequesting\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
requestor of a particular Reliable Transfer Service Element service.
.RT
.sp 1P
.LP
3.6.3
\fBaccepting\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
acceptor for a particular Reliable Transfer Service Element service.
.RT
.sp 1P
.LP
3.6.4
\fBsending\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
sender.
.RT
.sp 1P
.LP
3.6.5
\fBreceiving\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR :
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is the
receiver.
.RT
.sp 1P
.LP
3.6.6
\fBassociation\(hyinitiating\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR
:
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is
the association\(hyinitiator.
.RT
.sp 1P
.LP
3.6.7
\fBassociation\(hyresponding\(hyreliable\(hytransfer\(hyprotocol\(hymachine\fR
:
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine whose RTSE\(hyuser is
the association\(hyresponder.
.RT
.sp 2P
.LP
\fB4\fR \fBAbbreviations\fR
.sp 1P
.RT
.sp 1P
.LP
4.1
\fIData Units\fR
.sp 9p
.RT
.PP
APDU \
application\(hyprotocol\(hydata\(hyunit.
.RT
.sp 1P
.LP
4.2
\fITypes of Application\(hyprotocol\(hydata\(hyunits\fR
.sp 9p
.RT
.PP
The following abbreviations have been given to the
application\(hyprotocol\(hydata\(hyunits defined in this Recommendation.
.RT
.LP
RTAB
RT\(hyP\(hyABORT and RT\(hyU\(hyABORT
application\(hyprotocol\(hydata\(hyunit
.LP
RTORQ
RT\(hyOPEN\(hyREQUEST application\(hyprotocol\(hydata\(hyunit
.LP
RTOAC
RT\(hyOPEN\(hyACCEPT application\(hyprotocol\(hydata\(hyunit
.LP
RTORJ
RT\(hyOPEN\(hyREJECT application protocol\(hydata\(hyunit
.LP
RTTR
RT\(hyTRANSFER application\(hyprotocol\(hydata\(hyunit
.LP
RTTP
RT\(hyTOKEN\(hyPLEASE application\(hyprotocol\(hydata\(hyunit
.bp
.sp 1P
.LP
4.3
\fIOther Abbreviations\fR
.sp 9p
.RT
.PP
The following abbreviations are used in this
Recommendation.
.RT
.LP
AE
application\(hyentity
.LP
ACSE
Association Control Service Element
.LP
ASE
application\(hyservice\(hyelement
.LP
RTPM
reliable\(hytransfer\(hyprotocol\(hymachine
.LP
RT (or RTS)
Reliable Transfer
.LP
RTSE
Reliable Transfer Service Element
.sp 2P
.LP
\fB5\fR \fBConventions\fR
.sp 1P
.RT
.PP
This Recommendation employs a tabular presentation of its APDU
fields. In clause\ 7, tables are presented for each RTSE APDU. Each field is
summarized using the following notation:
.RT
.LP
M
presence is mandatory
.LP
U
presence is a RTSE service\(hyuser option
.LP
T
presence is a RTPM option
.LP
req
source is related request primitive
.LP
ind
sink is related indication primitive
.LP
resp
source is related response primitive
.LP
conf
sink is related confirm primitive
.LP
sp
source or sink is the RTPM
.PP
The structure of each RTSE APDU is specified in clause 9 using the abstract
syntax notation of Recommendation X.208.
.sp 2P
.LP
\fB6\fR \fBOverview of the Protocol\fR
.sp 1P
.RT
.sp 1P
.LP
6.1
\fIService Provision\fR
.sp 9p
.RT
.PP
The protocol specified in this Recommendation provides the services defined
in Recommendation\ X.218. These services are listed in
Table\ 1/X.228.
.RT
.LP
.sp 2
.ce
\fBH.T. [T1.228]\fR
.ce
TABLE\ 1/X.228
.ce
\fBRTSE Service Summary\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(78p) .
Service Type
_
.T&
lw(90p) | lw(78p) .
RT\(hyOPEN Confirmed
.T&
lw(90p) | lw(78p) .
RT\(hyCLOSE Confirmed
.T&
lw(90p) | lw(78p) .
RT\(hyTRANSFER Confirmed
.T&
lw(90p) | lw(78p) .
RT\(hyTURN\(hyPLEASE Non\(hyconfirmed
.T&
lw(90p) | lw(78p) .
RT\(hyTURN\(hyGIVE Non\(hyconfirmed
.T&
lw(90p) | lw(78p) .
RT\(hyP\(hyABORT Provider\(hyinitiated
.T&
lw(90p) | lw(78p) .
RT\(hyU\(hyABORT Non\(hyconfirmed
_
.TE
.nr PS 9
.RT
.ad r
\fBTable [T1.228], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
6.2
\fIUse of Services\fR
.sp 1P
.RT
.sp 1P
.LP
6.2.1
\fIACSE Services\fR
.sp 9p
.RT
.PP
The RTPM requires access to the A\(hyASSOCIATE, A\(hyRELEASE, A\(hyABORT
and A\(hyP\(hyABORT services. This Recommendation assumes that the RTPM
is the sole user of these services.
.RT
.sp 1P
.LP
6.2.2
\fIUse of the Presentation\(hyservice\fR
.sp 9p
.RT
.PP
The RTPM requires access to the P\(hyACTIVITY\(hySTART, P\(hyDATA,
P\(hyMINOR\(hySYNCHRONIZE,
P\(hyACTIVITY\(hyEND, P\(hyACTIVITY\(hyINTERRUPT,
P\(hyACTIVITY\(hyDISCARD,
P\(hyU\(hyEXCEPTION\(hyREPORT,
P\(hyACTIVITY\(hyRESUME, P\(hyP\(hyEXCEPTION\(hyREPORT,
P\(hyTOKEN\(hyPLEASE
and P\(hyCONTROL\(hyGIVE services. This Recommendation assumes that the
RTPM is the sole user of the above services.
.PP
The RTPM requires access to local syntax\(hymatching\(hyservices provided
by the presentation\(hyservice provider. This syntax\(hymatching\(hyservice
consists
of:
.RT
.LP
a)
an encoding service enabling the transformation from the
local representation of an APDU value into an encoded\(hyAPDU\(hyvalue
of type OCTET STRING the value of which is the representation of the APDU
value specified by the negotiated transfer syntax;
.LP
b)
a decoding service enabling the transformation from an
encoded\(hyAPDU\(hyvalue into the local representation of the APDU value.
.PP
If X.410\(hy1984 mode or simple encoding is used by the Presentation Layer,
the APDU value is encoded as ASN.1 type ANY. If full encoding is used by
the Presentation Layer, the APDU value is encoded as ASN.1 type EXTERNAL.
(For X.410\(hy1984 mode, single encoding and full encoding see Recommendation
X.226).
.PP
This Recommendation recognizes that the ACSE services require access to
the P\(hyCONNECT,
P\(hyRELEASE, P\(hyU\(hyABORT and P\(hyP\(hyABORT services. This
Recommendation assumes that the ACSE and the RTPM are the sole users of
any of the above, or of any other, presentation\(hyservices.
.PP
During the lifetime of an application\(hyassociation, the underlying
presentation\(hyconnections either use a single presentation context or
multiple presentation contexts as a part of the presentation multiple defined
context
facility. The choice is determined by the use of the Single Presentation
Context parameter of the RT\(hyOPEN service as described in clause\ 8.1.1.1.3
and\ 8.1.1.1.4.
.RT
.sp 1P
.LP
6.3
\fIModel\fR
.sp 9p
.RT
.PP
The reliable\(hytransfer\(hyprotocol\(hymachine (RTPM) communicates with
its service\(hyuser by means of primitives defined in Recommendation X.218.
Each
invocation of the RTPM controls a single application\(hyassociation.
.PP
The RTPM is driven by RTSE service request and response primitives
from its service\(hyuser, and by indication and confirm primitives from
the ACSE services and the presentation\(hyservice. The RTPM, in turn, issues
indication and confirm primitives to its service\(hyuser and request and
response primitives on the used ACSE services or presentation\(hyservice.
.PP
The reception of an RTSE service primitive, or of an ACSE service
primitive, or of a presentation\(hyservice primitive, and the generation of
dependent actions are considered to be indivisible.
.PP
During the use of the RTSE services, the existence of both the
association\(hyinitiating AE and the association\(hyresponding AE is presumed.
How
these AEs are created is beyond the scope of this Recommendation.
.PP
During the use of the RTSE services, except RT\(hyOPEN, the existence of
an application\(hyassociation between the peer AEs is presumed.
.PP
Note\ \(em\ Each application\(hyassociation may be identified in an end
system by an internal, implementation dependent mechanism so that the RTSE
service\(hyuser, and the RTPM, and the ACSE service\(hyprovider can refer to
it.
.bp
.RT
.sp 2P
.LP
\fB7\fR \fBElements of procedure\fR
.sp 1P
.RT
.PP
The RTSE protocol consists of the following elements of
procedure:
.RT
.LP
a)
association\(hyestablishment
.LP
b)
association\(hyrelease
.LP
c)
transfer
.LP
d)
turn\(hyplease
.LP
e)
turn\(hygive
.LP
f
)
error reporting:
.LP
f1)
user\(hyexception\(hyreport
.LP
f2)
provider\(hyexception\(hyreport
.LP
g)
error handling:
.LP
g1)
transfer\(hyinterrupt
.LP
g2)
transfer\(hydiscard
.LP
g3)
association\(hyabort
.LP
g4)
association\(hyprovider\(hyabort
.LP
h)
error recovery:
.LP
h1)
transfer\(hyresumption (for recovery from g1), or after successful h3)
from g3) or g4))
.LP
h2)
transfer\(hyretry (for recovery from g2))
.LP
h3)
association\(hyrecovery (for recovery from g3 or g4))
.LP
i)
abort:
.LP
i1)
transfer\(hyabort (recovery from g1) or g2) or g3) or
g4) not possible)
.LP
i2)
provider\(hyabort (recovery from g1) or g2) or g3) or
g4) not possible)
.LP
i3)
user\(hyabort.
.PP
In the following clauses, a summary of each of these elements of procedure
is presented. This consists of a summary of the relevant APDUs, and a high\(hylevel
overview of the relationship between the RTSE service primitives and the
APDUs involved and the used presentation\(hyservice.
.PP
Clause 8 describes how the service primitives are mapped on the ACSE services,
and on the presentation\(hyservice.
.RT
.sp 2P
.LP
7.1
\fIAssociation\(hyestablishment\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The association\(hyestablishment procedure is used to establish an
application\(hyassociation.
.RT
.sp 1P
.LP
7.1.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The association\(hyestablishment procedures uses the RT\(hyOPEN\(hyREQUEST
(RTORQ) APDU, the RT\(hyOPEN\(hyACCEPT (RTCAC) APDU, and the RT\(hyOPEN\(hyREJECT
(RTORJ) APDU.
.PP
\fINote\fR \ \(em\ These APDUs are also used in the association\(hyrecovery
procedure.
.RT
.sp 1P
.LP
7.1.2.1
\fIRTORQ APDU\fR
.sp 9p
.RT
.PP
The RT\(hyOPEN REQUEST (RTORQ) APDU is used in the request to
establish an application\(hyassociation. The fields of the RTORQ APDU are
listed in Table\ 2/X.228.
.RT
.sp 1P
.LP
7.1.2.2
\fIRTOAC APDU\fR
.sp 9p
.RT
.PP
The RT\(hyOPEN\(hyACCEPT (RTOAC) APDU is used in the positive response
to the request to establish an application\(hyassociation. The fields of
the RTOAC
APDU are listed in Table\ 3/X.228.
.bp
.RT
.ce
\fBH.T. [T2.228]\fR
.ce
TABLE\ 2/X.228
.ce
\fBRTORQ APDU Fields\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(30p) | cw(30p) .
Field name Presence Source Sink
_
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Checkpoint\(hysize T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Window\(hysize T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Dialogue\(hymode U req ind
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
User\(hydata (Note\ 1) U req ind
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
T{
Session\(hyconnection\(hyidentifier (Note\ 2)
T} T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
T{
Application\(hyprotocol (Note\ 3)
T} U req T{
ind
\fINote\ 1\fR
\ \(em\ The User\(hydata field is used solely in the association\(hyestablishment procedure.
.parag
\fINote\ 2\fR
\ \(em\ The Session\(hyconnection\(hyidentifier field is used solely in the
association\(hyrecovery procedure.
.parag
\fINote\ 3\fR
\ \(em\ The Application\(hyprotocol field is used solely in the
X.410\(hy1984 mode.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 2/X.228 [T2.228], p.2\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 4
.ce
\fBH.T. [T3.228]\fR
.ce
TABLE\ 3/X.228
.ce
\fBRTOAC APDU Fields\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(30p) | cw(30p) .
Field name Presence Source Sink
_
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Checkpoint\(hysize T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Window\(hysize T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
User\(hydata (Note 1) U resp conf
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
T{
Session\(hyconnection\(hyidentifier (Note 2)
T} T sp T{
sp
\fINote\ 1\fR
\ \(em\ The User\(hydata field is used solely in the association\(hyestablishment procedure.
.parag
\fINote\ 2\fR
\ \(em\ The Session\(hyconnection\(hyidentifier field is used solely in the
association\(hyrecovery procedure.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 3/X.228 [T3.228], p.3\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 2
7.1.2.3
\fIRTORJ APDU\fR
.sp 9p
.RT
.PP
RT\(hyOPEN\(hyREJECT (RTORJ) APDU is used in the negative response to
the request to establish an application\(hyassociation. The fields of the RTORJ
APDU are listed in Table\ 4/X.228.
.bp
.RT
.ce
\fBH.T. [T4.228]\fR
.ce
TABLE\ 4/X.228
.ce
\fBRTORJ APDU Fields\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(30p) | cw(30p) .
Field name Presence Source Sink
_
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Refuse\(hyreason (Note\ 1) T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
User\(hydata (Note\ 2) U resp T{
conf
\fINote\ 1\fR
\ \(em\ The Refuse\(hyreason field is used solely in the\ X.410\(hy1984 mode.
.parag
\fINote\ 2\fR
\ \(em\ The User\(hydata field is used solely in the normal mode, and is not
used in the association\(hyrecovery procedure.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 4/X.228 [T4.228], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.sp 1P
.LP
7.1.3
\fIAssociation\(hyestablishment procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an RT\(hyOPEN request primitive from the requestor
(association\(hyinitiator);
.LP
b)
an RTORQ APDU as user\(hydata on an A\(hyASSOCIATE indication
primitive;
.LP
c)
an RT\(hyOPEN response primitive from the acceptor
(association\(hyresponder);
.LP
d)
an A\(hyASSOCIATE confirm primitive that may contain either an RTOAC
APDU, or an RTORJ APDU, or no APDU.
.sp 1P
.LP
7.1.3.1
\fIRT\(hyOPEN request primitive\fR
.sp 9p
.RT
.PP
The requesting RTPM forms an RTORQ APDU from the parameter values of the
RT\(hyOPEN request primitive and its internal data. The RT\(hyOPEN request
primitive parameters, except user\(hydata, are stored by the requesting
RTPM for association\(hyrecovery. The requesting RTPM issues an A\(hyASSOCIATE
request
primitive also using information from the RT\(hyOPEN request primitive.
The RTORQ APDU is the user information parameter value of the A\(hyASSOCIATE
request
primitive.
.PP
The requesting RTPM waits for a primitive from the ACSE\(hyprovider and
does not accept any other primitive from the requestor.
.RT
.sp 1P
.LP
7.1.3.2
\fIRTORQ APDU\fR
.sp 9p
.RT
.PP
If the application\(hyassociation is not accepted by the
ACSE\(hyprovider, no A\(hyASSOCIATE indication primitive is received by
the accepting RTPM and no action takes place.
.PP
If the application\(hyassociation is accepted by the ACSE\(hyprovider,
the accepting RTPM receives the RTORQ APDU as the user information parameter
on an A\(hyASSOCIATE indication primitive.
.PP
If any of the A\(hyASSOCIATE indication parameters or any of the RTORQ
APDU fields is unacceptable to the accepting RTPM, or if the accepting
RTPM is not able to accept the application\(hyassociation, it forms and
sends an RTORJ
APDU with appropriate parameters from internal data. The accepting RTPM
issues an A\(hyASSOCIATE response primitive. The RTORJ APDU is sent as
the user
information parameter of the A\(hyASSOCIATE response primitive. The
application\(hyassociation is not established. The accepting RTPM does
not issue an RT\(hyOPEN indication.
.bp
.PP
If the A\(hyASSOCIATE indication primitive and the RTORQ APDU parameters
are acceptable to the accepting RTPM, it issues an RT\(hyOPEN indication
primitive to the acceptor. The RT\(hyOPEN indication parameter values are
derived from the RTORQ APDU and the A\(hyASSOCIATE indication primitive
parameter values.
.PP
The accepting RTPM waits for an RT\(hyOPEN response primitive from the
acceptor, or a primitive from the ACSE\(hyprovider.
.RT
.sp 1P
.LP
7.1.3.3
\fIRT\(hyOPEN response primitive\fR
.sp 9p
.RT
.PP
When the accepting RTPM receives an RT\(hyOPEN response primitive from
the acceptor, the result parameter specifies whether the acceptor has accepted
(value \*Qaccepted\*U) or rejected the application\(hyassociation.
.PP
If the application\(hyassociation is accepted by the acceptor, the
accepting RTPM forms an RTOAC APDU using the RT\(hyOPEN response primitive
parameters and internal data. The RT\(hyOPEN response primitive parameters,
except user data, are stored by the accepting RTPM for association\(hyrecovery.
.PP
The accepting RTPM issues an A\(hyASSOCIATE response primitive also using
information from the RT\(hyOPEN response primitive. The RTOAC APDU is sent
as the user information parameter of the A\(hyASSOCIATE response primitive.
.PP
If the application\(hyassociation is rejected by the acceptor, the
accepting RTPM forms a RTORJ APDU using the RT\(hyOPEN response primitive
parameters and internal data. The accepting RTPM issues an
A\(hyASSOCIATE
response
primitive also using information from the RT\(hyOPEN request primitive.
The RTORJ APDU is sent as the user information parameter of the A\(hyASSOCIATE
response
primitive. The application\(hyassociation is not established.
.RT
.sp 1P
.LP
7.1.3.4
\fIA\(hyASSOCIATE confirm primitive\fR
.sp 9p
.RT
.PP
The requesting RTPM receives an A\(hyASSOCIATE confirm primitive. The following
situations are possible:
.RT
.LP
a)
the application\(hyassociation has been accepted by the
acceptor;
.LP
b)
the accepting RTPM or the acceptor has rejected the
application\(hyassociation; or
.LP
c)
the ACSE service provider has rejected the
application\(hyassociation.
.PP
If the application\(hyassociation was accepted by the acceptor, the A\(hyASSOCIATE
confirm primitive result parameter has the value \*Qaccepted\*U and the
RTOAC APDU is the value of the user information parameter of the A\(hyASSOCIATE
confirm primitive. The requesting RTPM issues an RT\(hyOPEN confirm primitive
to the requestor. The result parameter has the value \*Qaccepted\*U and
the user\(hydata parameter contains the user\(hydata parameter value of
the RTOAC APDU. The other parameters of the RT\(hyOPEN confirm primitive
are derived from the A\(hyASSOCIATE
confirm primitive.
.PP
If the application\(hyassociation was rejected by either the acceptor or
the accepting RTPM, the
A\(hyASSOCIATE confirm primitive result parameter has one
of the values \*Qrejected\|.\|.\|.\*U, the A\(hyASSOCIATE confirm primitive
result source parameter has the value \*QACSE service\(hyuser\*U and the
RTORJ APDU is the value of the user information parameter of the A\(hyASSOCIATE
confirm primitive. The
requesting RTPM issues an RT\(hyOPEN confirm primitive to the requestor. The
result parameter has one of the values \*Qrejected\|.\|.\|.\*U and the
other parameter values are derived from the A\(hyASSOCIATE confirm primitive
parameters and the
RTORJ APDU. The application\(hyassociation is not established.
.PP
If the application\(hyassociation was rejected by the ACSE
service\(hyprovider, the A\(hyASSOCIATE confirm primitive result parameter
has one of the values \*Qrejected\|.\|.\|.\*U, the A\(hyASSOCIATE confirm
primitive result source
parameter has either the value \*QACSE service\(hyprovider\*U or \*Qpresentation
service\(hyprovider\*U. The user\(hydata parameter of the RT\(hyOPEN confirm
primitive is absent and the application\(hyassociation is not established.
The other parameters of the RT\(hyOPEN confirm primitive are derived from
the A\(hyASSOCIATE confirm
primitive.
.bp
.RT
.sp 1P
.LP
7.1.4
\fIUse of the RTORQ APDU fields\fR
.sp 9p
.RT
.PP
The RTORQ APDU fields are used as follows.
.RT
.sp 1P
.LP
7.1.4.1
\fICheckpoint\(hysize\fR
.sp 9p
.RT
.PP
The checkpoint\(hysize field allows negotiation of the maximum amount of
data (in units of 1024\ octets) that may be sent between two minor
synchronization points. A value of zero from the requesting RTPM invites the
accepting RTPM to select checkpoint\(hysize. If this field is absent,
checkpoint\(hysize zero is assumed.
.RT
.sp 1P
.LP
7.1.4.2
\fIWindow\(hysize\fR
.sp 9p
.RT
.PP
The window\(hysize field allows negotiation of the maximum number of outstanding
minor synchronization points before data transfer shall be
suspended. If this field is absent, window\(hysize\ 3 is assumed.
.RT
.sp 1P
.LP
7.1.4.3
\fIDialogue\(hymode\fR
.sp 9p
.RT
.PP
This is the dialogue\(hymode parameter value from the RT\(hyOPEN request
primitive. It appears as the dialogue\(hymode parameter value of the RT\(hyOPEN
indication primitive.
.PP
The value of this field is either monologue, or two\(hyway\(hyalternate.
If this field is absent, monologue is assumed.
.RT
.sp 1P
.LP
7.1.4.4
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This is the user\(hydata parameter value from the RT\(hyOPEN request
primitive. It appears as the user\(hydata paremeter value of the RT\(hyOPEN
indication primitive.
.PP
The value of this field is transparent to the RTPM.
.RT
.sp 1P
.LP
7.1.4.5
\fISession\(hyconnection\(hyidentifier\fR
.sp 9p
.RT
.PP
This field is used only in the association\(hyrecovery procedure.
.RT
.sp 1P
.LP
7.1.4.6
\fIApplication\(hyprotocol\fR
.sp 9p
.RT
.PP
This field is used solely in the X.410\(hy1984 mode. It is the
application\(hyprotocol parameter value from the RT\(hyOPEN request primitive.
It
appears as the application\(hyprotocol parameter value in the RT\(hyOPEN
indication primitive.
.RT
.sp 1P
.LP
7.1.5
\fIUse of the RTOAC APDU fields\fR
.sp 9p
.RT
.PP
The RTOAC APDU fields are used as follows.
.RT
.sp 1P
.LP
7.1.5.1
\fICheckpoint\(hysize\fR
.sp 9p
.RT
.PP
The checkpoint\(hysize field allows negotiation of the maximum amount of
data (in units of 1024\ octets) that may be sent between two minor
synchronization points. If the checkpoint\(hysize in the RTORQ APDU is greater
than zero, the accepting RTPM shall supply a value in the RTOAC APDU that is
less than or equal to the value in the RTORQ APDU, else the accepting RPTM
may select checkpoint\(hysize. A value of zero from the accepting RTPM
indicates that checkpointing will not be used. The value of this field
becomes the agreed
maximum value and governs both directions of transfer. If this field is
absent, it is assumed that checkpointing will not be used.
.RT
.sp 1P
.LP
7.1.5.2
\fIWindow\(hysize\fR
.sp 9p
.RT
.PP
This field is only used if checkpoint\(hysize of the RTOAC APDU is
greater than zero. The window\(hysize field allows negotiation of the maximum
number of outstanding minor synchronization points before data transfer
shall be suspended. The accepting RTPM shall supply a value that is less
than or
equal to the value in the RTORQ APDU. This becomes the agreed maximum size
and governs both directions of transfer. If this field is absent, window\(hysize\
3 is assumed.
.bp
.RT
.sp 1P
.LP
7.1.5.3
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This is the user\(hydata parameter value from the RT\(hyOPEN response
primitive. It appears as the user\(hydata parameter value of the RT\(hyOPEN
confirm service primitive.
.PP
The value of this field is transparent to the RTPM.
.RT
.sp 1P
.LP
7.1.5.4
\fISession\(hyconnection\(hyidentifier\fR
.sp 9p
.RT
.PP
This field is used only in the association\(hyrecovery procedure.
.RT
.sp 1P
.LP
7.1.6
\fIUse of the RTORJ APDU fields\fR
.sp 9p
.RT
.PP
The RTORJ APDU fields are used as follows.
.RT
.sp 1P
.LP
7.1.6.1
\fIRefuse\(hyreason\fR
.sp 9p
.RT
.PP
The refuse\(hyreason field is only used in the X.410\(hy1984 mode.
.PP
This field may contain one of the following values:
.RT
.LP
.sp 1
\(em
rts\(hybusy
The accepting RTPM, or the acceptor, is so loaded that it cannot
support a new application\(hyassociation. The requesting RTPM should retry
after a period of time. This value is either provided by the accepting
RTPM, or is derived from the result parameter value \*Qrejected (transient)\*U
of the RT\(hyOPEN response primitive from the acceptor. It appears as the
result parameter value \*Qrejected (transient)\*U of the RT\(hyOPEN confirm
primitive to the requestor.
.LP
\(em
cannot recover
This value is used only by the accepting RTPM in the
association\(hyrecovery procedure if it is unable to accept an
association\(hyrecovery.
\(em
validation failure
The acceptor does not recognize the requestor's credentials as being
valid for the proposed application\(hyassociation. This value is the
user\(hydata parameter value of the RT\(hyOPEN response primitive from the
acceptor. It appears as the user\(hydata parameter value of the RT\(hyOPEN
confirm primitive to the requestor.
.sp 1P
.LP
\(em
unacceptable\(hydialogue\(hymode
The acceptor does not accept the type of dialogue mode proposed for
the application\(hyassociation. This value is the user\(hydata parameter value
of the RT\(hyOPEN response primitive from the acceptor. It appears as the
user\(hydata parameter value of the RT\(hyOPEN confirm primitive to the
requestor.
7.1.6.2
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This field is only used in the normal mode:
.PP
This is the user\(hydata parameter value of the RT\(hyOPEN response
primitive from the acceptor. It appears as the user\(hydata parameter value
of the RT\(hyOPEN confirm primitive to the requestor.
.PP
The value of this field is transparent to the RTPM.
.bp
.RT
.sp 2P
.LP
7.2
\fIAssociation\(hyrelease\fR
.sp 1P
.RT
.sp 1P
.LP
7.2.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The association\(hyrelease procedure is used for the normal release of
an application\(hyassociation by the association\(hyinitiator without loss
of
information in transit.
.RT
.sp 1P
.LP
7.2.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.RT
.sp 1P
.LP
7.2.3
\fIAssociation\(hyrelease procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an RT\(hyCLOSE request primitive from the requestor
(association\(hyinitiator);
.LP
b)
an A\(hyRELEASE indication primitive;
.LP
c)
an RT\(hyCLOSE response primitive from the acceptor
(association\(hyresponder);
.LP
d)
an A\(hyRELEASE confirm primitive.
.sp 1P
.LP
7.2.3.1
\fIRT\(hyCLOSE request primitive\fR
.sp 9p
.RT
.PP
The requestor may issue an RT\(hyCLOSE request primitive only if it
possesses the turn and if there is no outstanding RT\(hyTRANSFER confirm
primitive. When an RT\(hyCLOSE request primitive is received from the requestor,
the requesting (association\(hyinitiating) RTPM issues an A\(hyRELEASE
request
primitive. The reason parameter of the A\(hyRELEASE request primitive is the
reason parameter of the RT\(hyCLOSE request primitive. The user information
parameter of the A\(hyRELEASE request primitive is the user\(hydata parameter
of the RT\(hyCLOSE request primitive.
.PP
\fINote\fR \ \(em\ No RT\(hyCLOSE request primitive parameters are present in
X.410\(hy1984 mode.
.PP
The requesting RTPM waits for a primitive from the ACSE
service\(hyprovider and does not accept any other primitive from the
requestor.
.RT
.sp 1P
.LP
7.2.3.2
\fIA\(hyRELEASE indication primitive\fR
.sp 9p
.RT
.PP
The accepting RTPM receives the A\(hyRELEASE indication
primitive.
.PP
It issues an RT\(hyCLOSE indication primitive to the acceptor. The
RT\(hyCLOSE indication parameter values are derived from the A\(hyRELEASE
indication primitive.
.PP
\fINote\fR \ \(em\ No RT\(hyCLOSE indication primitive parameters are present
in
X.410\(hy1984 mode.
.PP
The RTPM waits for a primitive from the acceptor or the used service provider.
.RT
.sp 1P
.LP
7.2.3.3
\fIRT\(hyCLOSE response primitive\fR
.sp 9p
.RT
.PP
When the accepting RTPM receives an RT\(hyCLOSE response primitive,
the accepting RTPM issues an A\(hyRELEASE response primitive. The reason
parameter of the A\(hyRELEASE response primitive is the reason parameter
of the RT\(hyCLOSE
response primitive. The user information parameter of the A\(hyRELEASE response
primitive is the user\(hydata parameter of the RT\(hyCLOSE response primitive.
The
result parameter value of the A\(hyRELEASE response primitive is \*Qaffirmative\*U.
.PP
\fINote\fR \ \(em\ No RT\(hyCLOSE response primitive parameters are present in
X.410\(hy1984 mode.
.bp
.RT
.sp 1P
.LP
7.2.3.4
\fIA\(hyRELEASE confirm primitive\fR
.sp 9p
.RT
.PP
The requesting RTPM receives an A\(hyRELEASE confirm primitive.
.PP
The requesting RTPM issues an RT\(hyOPEN confirm primitive to the
acceptor. The RT\(hyOPEN confirm primitive parameter values are derived
from the A\(hyRELEASE confirm primitive.
.PP
\fINote\fR \ \(em\ No RT\(hyCLOSE confirm primitive parameters are present in
X.410\(hy1984 mode.
.RT
.sp 2P
.LP
7.3
\fITransfer\fR
.sp 1P
.RT
.sp 1P
.LP
7.3.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The transfer procedure is used to transfer an RTSE\(hyuser APDU from the
requestor (sender) to the acceptor (receiver).
.RT
.sp 1P
.LP
7.3.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
Each RTSE\(hyuser APDU, conveyed in an RT\(hyTRANSFER request,
constitutes an activity. For each application\(hyassociation, at most one
activity, or one interrupted activity awaiting resumption, may exist at a
time.
.PP
The RTSE\(hyuser APDU value is transformed into the encoded\(hyAPDU\(hyvalue
and vice versa by means of the local syntax\(hymatching services. The transfer
procedure uses the RT\(hyTRANSFER (RTTR) APDU. The transfer procedure supports
segmenting and reassembling of the encoded\(hyAPDU\(hyvalue into/from one
or more
RTTR APDUs.
.PP
An encoded\(hyAPDU\(hyvalue is transferred as a single RTTR APDU if
checkpointing is not used. Otherwise, the encoded\(hyAPDU\(hyvalue is transferred
as a series of RTTR APDUs, the maximum size (i.e.\ number of octets forming
the
RTTR APDU value) of each being the negotiated checkpoint\(hysize. The
concatenation of the RTTR APDU values is the encoded\(hyAPDU\(hyvalue.
.PP
The fields of the RTTR APDU are listed in Table 5/X.228.
.RT
.LP
.sp 1
.ce
\fBH.T. [T5.228]\fR
.ce
TABLE\ 5/X.228
.ce
\fBRTTR APDU Fields\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(30p) | cw(30p) .
Field name Presence Source Sink
_
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
User\(hydata\(hypart M req ind/conf
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 5/X.228 [T5.228], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 1
7.3.3
\fITransfer procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an RT\(hyTRANSFER request primitive from the requestor
(sender);
.LP
b)
a P\(hyACTIVITY\(hySTART indication primitive, followed by one or more
RTTR APDUs as user\(hydata of P\(hyDATA indication primitives each, except
the last, followed by a P\(hyMINOR\(hySYNCHRONIZE indication primitive;
.LP
c)
a P\(hyMINOR\(hySYNCHRONIZE confirm primitive;
.LP
d)
a P\(hyACTIVITY\(hyEND indication primitive;
.LP
e)
a P\(hyACTIVITY\(hyEND confirm primitive;
.LP
f
)
a transfer time\(hyout.
.bp
.sp 1P
.LP
7.3.3.1
\fIRT\(hyTRANSFER request primitive\fR
.sp 9p
.RT
.PP
If the requesting RTPM possesses the turn and receives a
RT\(hyTRANSFER request from the requestor, the requesting RTPM transforms the
RTSE\(hyuser APDU value into the encoded\(hyAPDU\(hyvalue by means of the
encoding
service of the local syntax\(hymatching services.
.PP
The requesting RTPM issues a P\(hyACTIVITY\(hySTART request primitive and
may start transmitting the first RTTR APDU in a P\(hyDATA request primitive
immediately after the P\(hyACTIVITY\(hySTART request primitive is issued,
since the latter service is not a confirmed service.
.PP
The maximum RTTR APDU size will have been negotiated during the
association\(hyestablishment procedure. The requesting RTPM shall submit, in
P\(hyDATA request primitives, RTTR APDUs that conform to that agreement.
Checkpoints may only be inserted if a checkpoint\(hysize greater than zero was
negotiated during the association\(hyestablishment procedure.
.PP
If a transferred RTTR APDU is not the last in a series of RTTR APDUs used
to transfer a single encoded\(hyAPDU\(hyvalue, the requesting RTPM inserts
a
checkpoint by issuing a P\(hyMINOR\(hySYNCHRONIZE request primitive. The
requesting RTPM uses only the \*Qexplicit confirmation expected\*U type
of minor
synchronization. The requesting RTPM may issue further P\(hyDATA request
primitives and P\(hyMINOR\(hySYNCHRONIZE request primitives unless the agreed
window\(hysize has been reached.
.PP
If the RTTR APDU is the only one, or the last in a series of RTTR
APDUs used to transfer a single encoded\(hyAPDU\(hyvalue, the requesting
RTPM issues a P\(hyACTIVITY\(hyEND request primitive.
.PP
Consecutive P\(hyDATA request primitives shall not be issued, and all
data transfer shall take place within an activity.
.RT
.sp 1P
.LP
7.3.3.2
\fIP\(hyACTIVITY\(hySTART indication primitive, RTTR APDUs,\fR
\fIand P\(hyMINOR\(hySYNCHRONIZE indication primitives\fR
.sp 9p
.RT
.PP
The accepting RTPM receives a P\(hyACTIVITY\(hySTART indication
primitive, indicating the start of transfer of a RTSE\(hyuser APDU. The
accepting RTPM receives an RTTR APDU as user\(hydata of a P\(hyDATA indication
primitive.
.PP
If the RTTR APDU is not the last in a series of RTTR APDUs used to
transfer a single encoded\(hyAPDU\(hyvalue, the accepting RTPM receives a
P\(hyMINOR\(hySYNCHRONIZE indication primitive. If the accepting RTPM has
secured the RTTR APDU, it issues a P\(hyMINOR\(hySYNCHRONIZE response primitive.
.RT
.sp 1P
.LP
7.3.3.3
\fIP\(hyMINOR\(hySYNCHRONIZE confirmed primitive\fR
.sp 9p
.RT
.PP
When the requesting RTPM receives a P\(hyMINOR\(hySYNCHRONIZE confirm
primitive, it assumes that the accepting RTPM has secured the
encoded\(hyAPDU\(hyvalue APDU up to that point.
.PP
The requesting RTPM may issue further P\(hyDATA request primitives and
P\(hyMINOR\(hySYNCHRONIZE request primitives unless the agreed window\(hysize
has been reached. The window is advanced when a P\(hyMINOR\(hySYNCHRONIZE
confirm primitive is received by the requesting RTPM.
.PP
When a complete encoded\(hyAPDU\(hyvalue has been transmitted, the
requesting RTPM issues a
P\(hyACTIVITY\(hyEND request primitive.
.RT
.sp 1P
.LP
7.3.3.4
\fIP\(hyACTIVITY\(hyEND indication primitive\fR
.sp 9p
.RT
.PP
A P\(hyACTIVITY\(hyEND indication primitive indicates to the accepting
RTPM that a complete encoded\(hyAPDU\(hyvalue has been transferred. The
accepting
RTPM transforms the encoded\(hyAPDU\(hyvalue into the RTSE\(hyuser APDU
value by means of the decoding service of the local syntax\(hymatching\(hyservices.
.PP
If the accepting RTPM has secured the complete RTSE\(hyuser APDU, it
issues an RT\(hyTRANSFER indication primitive to the acceptor, and issues a
P\(hyACTIVITY\(hyEND response primitive.
.PP
The accepting RTPM records the session\(hyconnection\(hyidentifier and
the activity identifier of the last RTSE\(hyuser APDU which it completely
secured for association\(hyrecovery purposes.
.bp
.RT
.sp 1P
.LP
7.3.3.5
\fIP\(hyACTIVITY\(hyEND confirm primitive\fR
.sp 9p
.RT
.PP
An activity end is an implicit major synchronization point and once successfully
confirmed by means of an P\(hyACTIVITY\(hyEND confirm primitive, it
indicates to the requesting RTPM that the RTSE\(hyuser APDU has been secured by
the accepting RTPM. The requesting RTPM may then delete the transferred
RTSE\(hyuser APDU.
.PP
When the requesting RTPM receives the P\(hyACTIVITY\(hyEND confirm
primitive, it issues an RT\(hyTRANSFER confirm primitive with a result
parameter value of \*QAPDU\(hytransferred\*U to the requestor.
.RT
.sp 1P
.LP
7.3.3.6
\fITransfer time\(hyout\fR
.sp 9p
.RT
.PP
If an APDU has not been transferred within the time specified in
the transfer\(hytime parameter of the RT\(hyTRANSFER request primitive
(that is, the requesting RTPM has not received the P\(hyACTIVITY\(hyEND
confirm primitive), the
requesting RTPM performs the transfer\(hydiscard procedure followed by the
transfer\(hyabort procedure.
.PP
If during the transfer\(hydiscard procedure, the requesting RTPM does not
receive a P\(hyACTIVITY\(hyDISCARD confirm primitive within a (locally
specified)
reasonable time, the requesting RTPM performs the transfer\(hyabort procedure
followed by the provider\(hyabort procedure.
.RT
.sp 2P
.LP
7.4
\fITurn\(hyplease\fR
.sp 1P
.RT
.sp 1P
.LP
7.4.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The turn\(hyplease procedure is used by a receiver (requestor) to
request the turn from the sender (acceptor).
.RT
.sp 1P
.LP
7.4.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The turn\(hyplease procedure uses the RT\(hyTURN\(hyPLEASE (RTTP) APDU.
.PP
The fields of the RTTP APDU are listed in Table 6/X.228.
.RT
.LP
.ce
\fBH.T. [T6.228]\fR
.ce
TABLE\ 6/X.228
.ce
\fBRTTP APDU Fields\fR
.ce
\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(30p) | cw(30p) .
Field name Presence Source Sink
_
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Priority U req ind
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 6/X.228 [T6.228], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
7.4.3
\fITurn\(hyplease procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
am RT\(hyTURN\(hyPLEASE request primitive from the requestor;
.LP
b)
an RTTP APDU as user\(hydata of a P\(hyTOKEN\(hyPLEASE indication
primitive.
.sp 1P
.LP
7.4.3.1
\fIRT\(hyTURN\(hyPLEASE request primitive\fR
.sp 9p
.RT
.PP
If the requesting RTPM does not possess the turn and receives an
RT\(hyTURN\(hyPLEASE request from the requestor, the requesting RTPM issues a
P\(hyTOKEN\(hyPLEASE request primitive. If the priority parameter is present
in the RT\(hyTURN\(hyPLEASE request primitive, and RTTP APDU is formed
from the parameter
value and transferred as user\(hydata of the P\(hyTOKEN\(hyPLEASE request
primitive.
This procedure may be performed either inside or outside an activity.
.bp
.RT
.sp 1P
.LP
7.4.3.2
\fIRTTP APDU\fR
.sp 9p
.RT
.PP
If the accepting RTPM receives a P\(hyTOKEN\(hyPLEASE indication
primitive, the accepting RTPM issues an RT\(hyTURN\(hyPLEASE indication
primitive to the acceptor. If an RTTP APDU is transferred as user\(hydata
of the P\(hyTOKEN\(hyPLEASE indication primitive, the RT\(hyTURN\(hyPLEASE
indication primitive parameter is
present and derived from the RTTP APDU.
.RT
.sp 1P
.LP
7.4.4
\fIUse of the RTTP fields\fR
.sp 9p
.RT
.PP
The RTTP APDU fields are used as follows.
.RT
.sp 1P
.LP
7.4.4.1
\fIPriority\fR
.sp 9p
.RT
.PP
This is the priority parameter value of the RT\(hyTURN\(hyPLEASE request
primitive. It appears as the priority parameter value of the RT\(hyTURN\(hyPLEASE
indication primitive.
.PP
The value of this field is transparent to the RTPM.
.RT
.sp 2P
.LP
7.5
\fITurn\(hygive\fR
.sp 1P
.RT
.sp 1P
.LP
7.5.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The turn\(hygive procedure is used by a sender (requestor) to give the
turn to the receiver (acceptor). The requestor becomes the receiver and
the
acceptor becomes the sender.
.RT
.sp 1P
.LP
7.5.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.RT
.sp 1P
.LP
7.5.3
\fITurn\(hygive procedure\fR
.sp 9p
.RT
.PP
The turn\(hygive procedure is driven by the following
events:
.RT
.LP
a)
an RT\(hyTURN\(hyGIVE request primitive;
.LP
b)
a P\(hyCONTROL\(hyGIVE indication primitive.
.sp 1P
.LP
7.5.3.1
\fIRT\(hyTURN\(hyGIVE request primitive\fR
.sp 9p
.RT
.PP
If the requesting RTPM possesses the turn and receives an
RT\(hyTURN\(hyGIVE request primitive from the requestor, it issues a P\(hyCONTROL\(hyGIVE
request primitive and becomes the receiving RTPM. This may be done only
outside an activity.
.RT
.sp 1P
.LP
7.5.3.2
\fIP\(hyCONTROL\(hyGIVE indication primitive\fR
.sp 9p
.RT
.PP
If the accepting RTPM receives a P\(hyCONTROL\(hyGIVE indication
primitive, the accepting RTPM issues an RT\(hyTURN\(hyGIVE indication primitive
to
the acceptor, and issues a P\(hyCONTROL\(hyGIVE response primitive. The
accepting
RTPM becomes the sending RTPM.
.RT
.LP
7.6
\fIError reporting\fR
.sp 1P
.RT
.sp 2P
.LP
7.6.1
\fIUser\(hyexception\(hyreport\fR
.sp 1P
.RT
.sp 1P
.LP
7.6.1.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The user\(hyexception\(hyreport procedure is used by the receiving RTPM
to report an error situation to the sending RTPM.
.RT
.sp 1P
.LP
7.6.1.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.bp
.RT
.sp 1P
.LP
7.6.1.3
\fIUser\(hyexception\(hyreport procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
a receiving RTPM problem;
.LP
b)
a P\(hyU\(hyEXCEPTION\(hyREPORT indication primitive.
.sp 1P
.LP
7.6.1.3.1
\fIReceiving RTPM problem\fR
.sp 9p
.RT
.PP
If the receiving RTPM detects a problem, it issues a
P\(hyU\(hyEXCEPTION\(hyREPORT request primitive and starts a local recovery
timer.
Depending on the severity of the detected error, the value of the reason
parameter of the P\(hyU\(hyEXCEPTION\(hyREPORT request primitive is as
follows:
.RT
.LP
a)
In severe problem situations, the velue \*Qreceiving ability jeopardized\*U
is used.
.LP
b)
In exceptional circumstances, the receiving RTPM may have to delete a
partially received RTSE\(hyuser APDU, even though some minor
synchromization points have been confirmed. In this case, the value
\*Qunrecoverable procedure error\*U is used.
.LP
c)
If the receiving RTPM is not willing to complete a transfer procedure,
the value \*Qnon\(hyspecific error\*U is used.
.LP
d)
If the sending RTPM resumes a transfer procedure already
finished by the receiving RTPM (see clause\ 7.8.1.3.2), the value \*Qsequence
error\*U is used.
.LP
e)
For all other less severe error situations, the value \*Qlocal SS\(hyuser
error\*U is used.
.sp 1P
.LP
7.6.1.3.2
\fIP\(hyU\(hyEXCEPTION\(hyREPORT indication primitive\fR
.sp 9p
.RT
.PP
If the sending RTPM receives a P\(hyU\(hyEXCEPTION\(hyREPORT indication
primitive, it performs one of the following procedures depending on the
reason parameter value of the P\(hyU\(hyEXCEPTION\(hyREPORT indication
primitive:
.RT
.LP
a)
With a value \*Qreceiving ability jeopardized\*U, the
transfer\(hyabort procedure followed by the provider\(hyabort procedure are
performed.
.LP
b)
With a value \*Qunrecoverable procedure error\*U, the
transfer\(hydiscard procedure followed by transfer\(hyretry procedure are
performed.
.LP
c)
With a value \*Qnon\(hyspecific error\*U, the transfer\(hydiscard
procedure followed by the transfer\(hyabort procedure are performed.
.LP
d)
With a value \*Qsequence error\*U, the transfer\(hydiscard
procedure is performed and the requesting RTPM issues an RT\(hyTRANSFER confirm
primitive with a result parameter value of \*QAPDU\(hytransferred\*U to
the requestor and the transfer procedure is finished.
.LP
e)
With a value \*Qlocal SS\(hyuser error\*U and at least one
confirmed checkpoint in the transfer procedure, the transfer\(hyinterrupt
procedure followed by the transfer\(hyresumption procedure are performed. If no
checkpoint was confirmed in the transfer procedure, the transfer\(hydiscard
procedure followed by the transfer\(hyretry procedure are performed.
.sp 2P
.LP
7.6.2
\fIProvider\(hyexception\(hyreport\fR
.sp 1P
.RT
.sp 1P
.LP
7.6.2.1
\fIPurpose\fR
.sp 9p
.RT
.PP
If the presentation service\(hyprovider detects an unexpected
situation during an activity, not covered by other services, a
P\(hyP\(hyEXCEPTION\(hyREPORT indication primitive is issued to both RTPMs.
.RT
.sp 1P
.LP
7.6.2.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.bp
.RT
.sp 1P
.LP
7.6.2.3
\fIProvider\(hyexception\(hyreport procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
a P\(hyP\(hyEXCEPTION\(hyREPORT indication primitive.
.sp 1P
.LP
7.6.2.3.1
\fIP\(hyP\(hyEXCEPTION\(hyREPORT indication primitive\fR
.sp 9p
.RT
.PP
The receiving RTPM receives a P\(hyP\(hyEXCEPTION\(hyREPORT indication
primitive.
.PP
If the sending RTPM receives a P\(hyP\(hyEXCEPTION\(hyREPORT indication
primitive, it may perform one of the following procedures:
.RT
.LP
a)
if at least one checkpoint was confirmed in the transfer
procedure, the transfer\(hyinterrupt procedure followed by the
transfer\(hyresumption procedure; or,
.LP
b)
if no checkpoint was confirmed in the transfer procedure,
the transfer\(hydiscard procedure followed by the transfer\(hyretry procedure;
or,
.LP
c)
the transfer\(hyabort procedure followed by the provider\(hyabort procedure.
.LP
7.7
\fIError handling\fR
.sp 1P
.RT
.sp 2P
.LP
7.7.1
\fITransfer\(hyinterrupt\fR
.sp 1P
.RT
.sp 1P
.LP
7.7.1.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The transfer\(hyinterrupt procedure is used by the sending RTPM to
handle a less severe (than those handled by the other error handling
procedures) error situation during the transfer procedure, if at least one
checkpoint was confirmed during the transfer procedure.
.RT
.sp 1P
.LP
7.7.1.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.RT
.sp 1P
.LP
7.7.1.3
\fITransfer\(hyinterrupt procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
a sending RTPM problem;
.LP
b)
a P\(hyACTIVITY\(hyINTERRUPT indication primitive;
.LP
c)
a P\(hyACTIVITY\(hyINTERRUPT confirm primitive.
.sp 1P
.LP
7.7.1.3.1
\fISending RTPM problem\fR
.sp 9p
.RT
.PP
If the sending RTPM detects a less severe problem and at least one checkpoint
was confirmed during the transfer procedure, it issues a
P\(hyACTIVITY\(hyINTERRUPT request primitive with one of the following reason
parameter values:
.RT
.LP
a)
\*Qnon\(hyspecific error\*U, if the problem was indicated by an
error reporting procedure;
.LP
b)
\*Qlocal SS\(hyuser error\*U, if the problem is a local sending
RTPM problem.
.sp 1P
.LP
7.7.1.3.2
\fIP\(hyACTIVITY\(hyINTERRUPT indication primitive\fR
.sp 9p
.RT
.PP
If the receiving RTPM receives a P\(hyACTIVITY\(hyINTERRUPT indication
primitive, it issues a
P\(hyACTIVITY\(hyINTERRUPT response primitive and starts a local recovery
timer.
.RT
.sp 1P
.LP
7.7.1.3.3
\fIP\(hyACTIVITY\(hyINTERRUPT confirm primitive\fR
.sp 9p
.RT
.PP
If the sending RTPM receives a P\(hyACTIVITY\(hyINTERRUPT confirm
primitive, it starts the transfer\(hyresumption procedure.
.bp
.RT
.sp 2P
.LP
7.7.2
\fITransfer\(hydiscard\fR
.sp 1P
.RT
.sp 1P
.LP
7.7.2.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The transfer\(hydiscard procedure is used by the sending RTPM to
escape from a more severe (than those handled by the transfer\(hyinterrupt
procedure) error situation, or a less severe error situation if no checkpoint
was confirmed, during the transfer procedure.
.RT
.sp 1P
.LP
7.7.2.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.RT
.sp 1P
.LP
7.7.2.3
\fITransfer\(hydiscard procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
a sending RTPM problem;
.LP
b)
a P\(hyACTIVITY\(hyDISCARD indication primitive;
.LP
c)
a P\(hyACTIVITY\(hyDISCARD confirm primitive.
.sp 1P
.LP
7.7.2.3.1
\fISending RTPM problem\fR
.sp 9p
.RT
.PP
If the sending RTPM detects a more severe problem, or a less severe problem
if no checkpoint was confirmed during the transfer procedure, it issues
a P\(hyACTIVITY\(hyDISCARD request primitive with one of the following
Reason
parameter values:
.RT
.LP
a)
\*Qnon\(hyspecific error\*U, if the problem was indicated by an
error reporting procedure;
.LP
b)
\*Qlocal SS\(hyuser error\*U, or \*Qunrecoverable procedural error\*U,
if the problem is a local sending RTPM problem.
.sp 1P
.LP
7.7.2.3.2
\fIP\(hyACTIVITY\(hyDISCARD indication primitive\fR
.sp 9p
.RT
.PP
If the receiving RTPM receives a P\(hyACTIVITY\(hyDISCARD indication
primitive, it issues a P\(hyACTIVITY\(hyDISCARD response primitive. The
receiving
RTPM deletes all knowledge and contents of the associated RTSE\(hyuser
APDU so far received.
.PP
If the receiving RTPM has already issued an RT\(hyTRANSFER indication
primitive, it performs the association\(hyabort procedure. The abort\(hyreason
field value of the RTAB APDU is \*Qtransfer\(hycompleted\*U. In this case
the sending RTPM ends the transfer procedure with a positive RT\(hyTRANSFER
confirm primitive and the association\(hyrecovery procedure is performed.
.RT
.sp 1P
.LP
7.7.2.3.3
\fIP\(hyACTIVITY\(hyDISCARD confirm primitive\fR
.sp 9p
.RT
.PP
The receipt of a P\(hyACTIVITY\(hyDISCARD confirm primitive by the
sending RTPM signifies the completion of the transfer\(hydiscard procedure.
.RT
.sp 2P
.LP
7.7.3
\fIAssociation\(hyabort\fR
.sp 1P
.RT
.sp 1P
.LP
7.7.3.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The association\(hyabort procedure is used by the RTPMs to handle the most
severe error situations. This procedure can be performed between an
RT\(hyTRANSFER request primitive and its corresponding RT\(hyTRANSFER confirm
primitive.
.RT
.sp 1P
.LP
7.7.3.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The association\(hyabort procedure uses the RT\(hyABORT (RTAB) APDU. The
fields of the RTAB APDU are listed in Table\
7B/FX.228.
.PP
\fINote\fR \ \(em\ The RTAB APDU is also used by the provider\(hyabort and the
user\(hyabort procedure.
.bp
.RT
.ce
\fBH.T. [T7.228]\fR
.ce
TABLE\ 7/X.228
.ce
\fBRTAB APDU Fields\fR
.ce
\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(30p) | cw(30p) | cw(30p) .
Field name Presence Source Sink
_
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Abort\(hyreason T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
Reflected\(hyparameter T sp sp
.T&
lw(90p) | cw(30p) | cw(30p) | cw(30p) .
User\(hydata U req ind
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 7/X.228 [T7.228], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
7.7.3.3
\fIAssociation\(hyabort procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an RTPM\(hyabort;
.LP
b)
an RTAB APDU.
.sp 1P
.LP
7.7.3.3.1
\fIRTPM\(hyabort\fR
.sp 9p
.RT
.PP
Either the receiving or the sending RTPM transfers an RTAB APDU to its
peer as user\(hydata of an A\(hyABORT request primitive. If the RTPM is
the\fR
association\(hyinitiating RTPM, it performs the association recovery procedure.
If the RTPM is the association\(hyresponding RTPM, it awaits association\(hyrecovery.
The receiving RTPM starts a local recovery timer.
.PP
After successful association recovery, the sending RTPM performs the transfer\(hyresumption
procedure.
.RT
.sp 1P
.LP
7.7.3.3.2
\fIRTAB APDU\fR
.sp 9p
.RT
.PP
Either the sending RTPM or the receiving RTPM may receive an RTAB APDU
as user\(hydata of an A\(hyABORT indication primitive. If the RTPM is the
association\(hyinitiating RTPM, it performs the association\(hyrecovery
procedure. If the RTPM is the association\(hyresponding RTPM, it awaits
association recovery.
The receiving RTPM starts a local recovery timer.
.PP
After successful association recovery, the sending RTPM performs the transfer\(hyresumption
procedure.
.RT
.sp 1P
.LP
7.7.3.4
\fIUse of the RTAB APDU fields\fR
.sp 9p
.RT
.PP
The RTAB APDU fields are used as follows:
.RT
.sp 1P
.LP
7.7.3.4.1
\fIAbort\(hyreason\fR
.sp 9p
.RT
.PP
This field may contain one of the following values:
.RT
.LP
.sp 1
\(em
local\(hysystem\(hyproblem
\(em
invalid\(hyparameter
The invalid parameters are specified in the reflected\(hyparameter
field.
\(em
unrecognized\(hyactivity
The sending RTPM shall perform the transfer\(hyabort procedure optionally
followed by the provider\(hyabort procedure.
\(em
temporary\(hyproblem
No attempt at association\(hyrecovery should be made for a period of
time determined by a local rule.
.LP
\(em
protocol\(hyerror
Of the RTPM.
\(em
permanent\(hyerror
This value is used solely by the provider\(hyabort procedure in normal
mode.
\(em
user\(hyabort
This value is used solely by the user\(hyabort procedure in normal
mode.
\(em
transfer\(hycompleted
The receiving RTPM could not discard an already completed
transfer.
.bp
.sp 1P
.LP
7.7.3.4.2
\fIReflected\(hyparameter\fR
.sp 9p
.RT
.PP
The reflected\(hyparameter field is a bit string that identifies which
parameters are regarded as invalid parameters in the primitive received
from
the used service by the aborting RTMP before the association\(hyabort.
The order of the bits in the bit string is the same as the order of the
parameters in the tables of service parameters in Recommendations\ X.217
and\ X.216 (i.e.\ bit\ 1
represents the first parameter,\ etc.).
.RT
.sp 1P
.LP
7.7.3.4.3
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This field is not used in the association\(hyabort procedure.
.bp
.RT
.sp 2P
.LP
7.7.4
\fIAssociation\(hyprovider\(hyabort\fR
.sp 1P
.RT
.sp 1P
.LP
7.7.4.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The association\(hyprovider\(hyabort procedure is used to handle an
ACSE\(hyprovider, or a presentation service\(hyprovider abort.
.RT
.sp 1P
.LP
7.7.4.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.RT
.sp 1P
.LP
7.7.4.3
\fIAssociation\(hyprovider\(hyabort procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following event:
.RT
.LP
a)
an AP\(hyABORT indication primitive.
.sp 1P
.LP
7.7.4.3.1
\fIAP\(hyABORT indication primitive\fR
.sp 9p
.RT
.PP
An association\(hyprovider\(hyabort is indicated to both RTPMs by an
AP\(hyABORT indication primitive, and may occur at any time.
.PP
After such an event, the association\(hyinitiating RTPM starts the
association\(hyrecovery procedure. Both RTPMs start a local recovery timer.
.PP
If the association\(hyprovider\(hyabort procedure was performed during
the transfer procedure, the sending RTPM starts the transfer\(hyresumption
procedure after the association\(hyrecovery procedure is successfully completed.
If the
association\(hyrecovery procedure was not successfully completed, the sending
RTPM performs the transfer\(hyerror procedure, and the provider\(hyabort
procedure.
.RT
.LP
7.8
\fIError recovery\fR
.sp 1P
.RT
.sp 2P
.LP
7.8.1
\fITransfer\(hyresumption\fR
.sp 1P
.RT
.sp 1P
.LP
7.8.1.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The transfer\(hyresumption procedure is used by the sending RTPM to
recover from:
.RT
.LP
a)
an error situation handled by the transfer\(hyinterrupt
procedure; or,
.LP
b)
an error situation handled by the association\(hyabort
procedure during a transfer procedure. In this case the transfer\(hyresumption
procedure is performed after an association\(hyrecovery procedure is successfully
performed. If no checkpoint was confirmed in the interrupted transfer
procedure, the transfer\(hydiscard procedure followed by the transfer\(hyretry
procedure are performed after transfer\(hyresumption.
.sp 1P
.LP
7.8.1.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The transfer\(hyresumption procedure uses the RTTR APDU (see clause
7.3.2).
.RT
.sp 1P
.LP
7.8.1.3
\fITransfer\(hyresumption procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
the resumption of an interrupted activity;
.LP
b)
a P\(hyACTIVITY\(hyRESUME indication primitive.
.PP
After these events, the transfer procedure is used to continue
(see clause\ 7.3.3).
.bp
.sp 1P
.LP
7.8.1.3.1
\fIResumption of an interrupted activity\fR
.sp 9p
.RT
.PP
The sending RTPM issues a P\(hyACTIVITY\(hyRESUME request primitive with
parameters that link the resumed Activity to the previously interrupted
one.
.PP
After the sending RTPM has issued the P\(hyACTIVITY\(hyRESUME request
primitive and at least one checkpoint was confirmed in the interrupted
transfer procedure, it continues the transfer procedure by issuing a P\(hyDATA
request
primitive for the RTTR APDU following the last confirmed checkpoint. If no
checkpoint was confirmed in the interrupted transfer procedure, the
transfer\(hydiscard procedure followed by the transfer\(hyretry procedure are
performed.
.RT
.sp 1P
.LP
7.8.1.3.2
\fIP\(hyACTIVITY\(hyRESUME indication primitive\fR
.sp 9p
.RT
.PP
If the receiving RTPM receives a P\(hyACTIVITY\(hyRESUME indication
primitive, it checks the Old Activity Identifier and the Old Session Connection
Identifier parameters of the P\(hyACTIVITY\(hyRESUME indication primitive
with the
corresponding information (session\(hyconnection\(hyidentifier, and Activity
Identifier) recorded for the last completely secured transfer (see
clause\ 7.3.3.4).
.PP
If the information coincides, the receiving RTPM either:
.RT
.LP
a)
responds correctly to the sending RTPM according to the
transfer procedure, but discards the data it receives, and does not issue an
RT\(hyTRANSFER indication primitive; or,
.LP
b)
performs the user\(hyexception\(hyreport procedure with a Reason parameter
value of \*Qsequence error\*U.
.PP
If the information does not coincide, and the old Activity
Identifier and the old Session Connection Identifier parameters match the
corresponding information of the previously interrupted activity, the
transfer\(hyresumption procedure continues as for the transfer procedure with a
P\(hyDATA indication primitive for the RTTR APDU following the last confirmed
checkpoint.
.PP
If the receiving RTPM cannot resume the activity, the receiving RTPM performs
the user\(hyexception\(hyreport procedure or the association\(hyabort
procedure.
.RT
.sp 2P
.LP
7.8.2
\fITransfer\(hyretry\fR
.sp 1P
.RT
.sp 1P
.LP
7.8.2.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The transfer\(hyretry procedure is used by the sending RTPM to recover
from an error situation handled by the transfer\(hydiscard procedure.
.PP
The completion of this procedure is as for the transfer
procedure.
.RT
.sp 1P
.LP
7.8.2.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The transfer\(hyretry procedure uses the RTTR APDU (see
clause\ 7.3.2).
.RT
.sp 1P
.LP
7.8.2.3
\fITransfer\(hyretry procedure\fR
.sp 9p
.RT
.PP
The sending RTPM performs the transfer procedure (see
clause\ 7.3.3). A new Activity Identifier parameter value is used in the
P\(hyACTIVITY\(hySTART request primitive.
.RT
.sp 2P
.LP
7.8.3
\fIAssociation\(hyrecovery\fR
.sp 1P
.RT
.sp 1P
.LP
7.8.3.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The association\(hyrecovery procedure is used by the
association\(hyinitiating RTPM to recover from an error situation handled
by the association\(hyabort procedure or the association\(hyprovider\(hyabort
procedure.
.RT
.sp 1P
.LP
7.8.3.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The association\(hyrecovery procedure uses the RT\(hyOPEN\(hyREQUEST (RTORQ)
APDU, the RT\(hyOPEN\(hyACCEPT (RTOAC) APDU, and the RT\(hyOPEN\(hyREJECT
(RTORJ)
APDU.
.bp
.RT
.sp 1P
.LP
7.8.3.2.1
\fIRTORQ APDU\fR
.sp 9p
.RT
.PP
The RT\(hyOPEN\(hyREQUEST (RTORQ) APDU is used in the request to recover
an application\(hyassociation. The fields of the RTORQ APDU are listed
in
clause\ 7.1.2.1.
.PP
The following rules apply:
.RT
.LP
a)
the User\(hydata field is not used;
.LP
b)
the Session\(hyconnection\(hyidentifier field is mandatory.
.sp 1P
.LP
7.8.3.2.2
\fIRTOAC APDU\fR
.sp 9p
.RT
.PP
The RT\(hyOPEN\(hyACCEPT (RTOAC) APDU is used in the positive response
to the request to recover an application\(hyassociation. The fields of
the RTOAC APDU are listed in clause\ 7.1.2.2.
.PP
The following rules apply:
.RT
.LP
a)
the User\(hydata field is not used;
.LP
b)
the Session\(hyconnection\(hyidentifier field is mandatory.
.sp 1P
.LP
7.8.3.2.3
\fIRTORJ APDU\fR
.sp 9p
.RT
.PP
The RT\(hyOPEN\(hyREJECT (RTORJ) APDU is used in the negative response
to the request to recover an application\(hyassociation. The fields of
the RTORJ APDU are listed in clause\ 7.1.2.3.
.PP
The following rules apply:
.RT
.LP
a)
the Refuse\(hyreason field is used solely in the X.410\(hy1984
mode;
.LP
b)
the User\(hydata field is not used.
.sp 1P
.LP
7.8.3.3
\fIAssociation\(hyrecovery procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an A\(hyASSOCIATE request primitive by the
association\(hyinitiating RTPM;
.LP
b)
an RTORQ APDU as user\(hydata on an A\(hyASSOCIATE indication
primitive;
.LP
c)
an A\(hyASSOCIATE confirm primitive that may contain either an RTOAC
APDU, or an RTORJ, or no APDU.
.sp 1P
.LP
7.8.3.3.1
\fIA\(hyASSOCIATE request primitive\fR
.sp 9p
.RT
.PP
The association\(hyinitiating RTPM forms an RTORQ APDU from its
internal data. The association\(hyinitiating RTPM issues an A\(hyASSOCIATE
request
primitive using information stored during the association\(hyestablishment
procedure (see clause\ 7.1.3.1). The RTORQ APDU is the User Information
parameter value of the A\(hyASSOCIATE request primitive.
.PP
The association\(hyinitiating RTPM waits for a primitive from the ACSE
service\(hyprovider.
.RT
.sp 1P
.LP
7.8.3.3.2
\fIRTORQ APDU\fR
.sp 9p
.RT
.PP
If the application\(hyassociation is not accepted by the ACSE
service\(hyprovider, no A\(hyASSOCIATE indication primitive is received by the
association\(hyresponding RTPM and no action takes place.
.PP
If the application\(hyassociation is accepted by the ACSE
service\(hyprovider, the association\(hyresponding RTPM receives the RTORQ
APDU as
the User Information parameter on an A\(hyASSOCIATE indication primitive.
.PP
If any of the A\(hyASSOCIATE indication primitive parameters, or any of
the RTORQ APDU fields, is unacceptable to the association\(hyresponding
RTPM, or if the association\(hyresponding RTPM is not able to accept the
application\(hyassociation, it forms and sends an RTORJ APDU with appropriate
parameters from internal data. The association\(hyresponding RTPM issues an
A\(hyASSOCIATE response primitive. The RTORJ APDU is sent as the User Information
parameter of the A\(hyASSOCIATE response primitive. The application\(hyassociation
is not recovered.
.bp
.PP
If the A\(hyASSOCIATE indication primitive parameters, and the RTORQ APDU
fields are acceptable to the association\(hyresponding RTPM, the
association\(hyresponding RTPM forms an RTOAC APDU using
internal data. The association\(hyresponding RTPM issues an A\(hyASSOCIATE
response primitive. The RTOAC APDU is sent as the User Information parameter
of the
A\(hyASSOCIATE response primitive.
.RT
.sp 1P
.LP
7.8.3.3.3
\fIA\(hyASSOCIATE confirm primitive\fR
.sp 9p
.RT
.PP
The association\(hyinitiating RTPM receives an A\(hyASSOCIATE confirm
primitive. The following situations are possible:
.RT
.LP
a)
the association\(hyrecovery has been accepted;
.LP
b)
the accepting RTPM has rejected the association\(hyrecovery;
or
.LP
c)
the ACSE service provider has rejected the
association\(hyrecovery.
.PP
If the association\(hyrecovery was accepted, the A\(hyASSOCIATE confirm
primitive Result parameter has the value \*Qaccepted\*U and the RTOAC APDU
is the value of the User Information Parameter of the A\(hyASSOCIATE confirm
primitive. The application\(hyassociation is recovered successfully, and
if the
association\(hyabort occurred during the transfer procedure, the sending RTPM
continues with the transfer\(hyresumption procedure.
.PP
If the association\(hyrecovery was rejected by the responding RTPM, the
A\(hyASSOCIATE confirm primitive Result parameter has one of the values
\*Qrejected\|.\|.\|.\*U, the A\(hyASSOCIATE confirm primitive Result Source
parameter has the value \*QACSE service\(hyuser\*U and the RTORJ APDU is
the value of the User
Information Parameter of the A\(hyASSOCIATE confirm primitive. The
application\(hyassociation is not recovered.
.PP
If the association\(hyrecovery was rejected by the ACSE service\(hyprovider,
the A\(hyASSOCIATE confirm primitive Result parameter has one of the values
\*Qrejected\|.\|.\|.\*U and the A\(hyASSOCIATE confirm primitive Result
Source parameter has either the value \*QACSE service\(hyprovider\*U or
\*Qpresentation
service\(hyprovider\*U. The application\(hyassociation is not recovered.
.PP
If the application\(hyassociation was not recovered, the
association\(hyrecovery procedure is performed again by the association\(hyinitiating
RTPM after a time determined by a local rule:
.RT
.LP
a)
if the Result parameter of the A\(hyASSOCIATE confirm primitive has the
following value \*Qrejected (transient)\*U; or
.LP
b)
if, in X.410\(hy1984 mode, the Refuse\(hyreason field of the RTORJ APDU
has the value \*Qrts\(hybusy\*U.
.PP
In all other cases a provider\(hyabort is performed as follows.
.PP
If the association\(hyinitiating RTPM is the sending RTPM, and the
association\(hyabort occurred during the transfer procedure, the sending RTPM
performs the transfer\(hyabort procedure. The association\(hyinitiating
RTPM performs the provider\(hyabort procedure.
.PP
If the association\(hyresponding RTPM detects a recovery\(hytime\(hyout, the
following actions take place. If the association\(hyresponding RTPM is
the sending RTPM, and the association\(hyabort occurred during the transfer
procedure, the
sending RTPM performs the transfer\(hyabort procedure. The association\(hyresponding
RTPM performs the provider\(hyabort procedure.
.RT
.sp 1P
.LP
7.8.3.4
\fIUse of the RTORQ APDU fields\fR
.sp 9p
.RT
.PP
The RTORQ APDU fields are used as follows.
.RT
.sp 1P
.LP
7.8.3.4.1
\fICheckpoint\(hysize\fR
.sp 9p
.RT
.PP
See clause 7.1.4.1.
.RT
.sp 1P
.LP
7.8.3.4.2
\fIWindow\(hysize\fR
.sp 9p
.RT
.PP
See clause 7.1.4.2.
.RT
.sp 1P
.LP
7.8.3.4.3
\fIDialogue\(hymode\fR
.sp 9p
.RT
.PP
See clause 7.1.4.3.
.bp
.RT
.sp 1P
.LP
7.8.3.4.4
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This field is not used in the association\(hyrecovery procedure.
.RT
.sp 1P
.LP
7.8.3.4.5
\fISession\(hyconnection\(hyidentifier\fR
.sp 9p
.RT
.PP
The Session\(hyconnection\(hyidentifier is used to specify the original
session connection used in the association\(hyestablishment procedure.
This is
used in order to relate the new session\(hyconnection to the existing
application\(hyassociation.
.RT
.sp 1P
.LP
7.8.3.5
\fIUse of the RTOAC APDU fields\fR
.sp 9p
.RT
.PP
The RTOAC APDU fields are used as follows.
.RT
.sp 1P
.LP
7.8.3.5.1
\fICheckpoint\(hysize\fR
.sp 9p
.RT
.PP
See clause 7.1.5.1.
.RT
.sp 1P
.LP
7.8.3.5.2
\fIWindow\(hysize\fR
.sp 9p
.RT
.PP
See clause 7.1.5.2.
.RT
.sp 1P
.LP
7.8.3.5.3
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This field is used only in the association\(hyrecovery procedure.
.RT
.sp 1P
.LP
7.8.3.5.4
\fISession\(hyconnection\(hyidentifier\fR
.sp 9p
.RT
.PP
The Session\(hyconnection\(hyidentifier is used to specify the original
session connection used in the association\(hyestablishment procedure.
This is
used in order to relate the new session\(hyconnection to the existing
application\(hyassociation.
.RT
.sp 1P
.LP
8.3.6
\fIUse of the RTORJ APDU fields\fR
.sp 9p
.RT
.PP
The RTORJ APDU fields are used as follows.
.RT
.sp 1P
.LP
7.8.3.6.1
\fIRefuse\(hyreason\fR
.sp 9p
.RT
.PP
The Refuse\(hyreason field is used solely in the X.410\(hy1984 mode.
.PP
This field may contain one of the following values:
.RT
.LP
.sp 1
\(em
rts\(hybusy
The association\(hyresponding RTPM is so loaded that it cannot support
the application\(hyassociation. The association\(hyinitiating RTPM should
retry after a period of time. This value is provided by the
association\(hyresponding RTPM.
\(em
cannot recover
This value is used by the association\(hyresponding RTPM, if it is unable
to accept an association\(hyrecovery.
.sp 1P
.LP
7.8.3.6.4
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This field is not used in the association\(hyrecovery procedure.
.RT
.sp 1P
.LP
7.9
\fIAbort\fR
.sp 9p
.RT
.PP
These procedures are performed when a successful recovery from one of the
error handling procedures is not possible.
.bp
.RT
.sp 2P
.LP
7.9.1
\fITransfer\(hyabort\fR
.sp 1P
.RT
.sp 1P
.LP
7.9.1.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The transfer\(hyabort procedure is used by the sending RTPM if the
transfer of an RTSE\(hyuser APDU is not possible.
.RT
.sp 1P
.LP
7.9.1.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
No APDUs are used in this procedure.
.RT
.sp 1P
.LP
7.9.1.3
\fITransfer\(hyabort procedure\fR
.sp 9p
.RT
.PP
The sending RTPM issues an RT\(hyTRANSFER confirm primitive with a
Result parameter value \*QAPDU\(hynot\(hytransferred\*U. The APDU parameter
value is the RTSE\(hyuser APDU not transferred.
.RT
.sp 2P
.LP
7.9.2
\fIProvider\(hyabort\fR
.sp 1P
.RT
.sp 1P
.LP
7.9.2.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The provider\(hyabort procedure is used by the RTPMs, if recovery is not
possible.
.RT
.sp 1P
.LP
7.9.2.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
If an application\(hyassociation exists, the provider\(hyabort procedure
uses the RT\(hyABORT (RTAB) APDU. The RTAB APDU is specified in
clause\ 7.7.3.2.
.RT
.sp 1P
.LP
7.9.2.3
\fIProvider\(hyabort procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an RTPM\(hyabort;
.LP
b)
an RTAB APDU;
.LP
c)
local recovery time\(hyout.
.sp 1P
.LP
7.9.2.3.1
\fIRTPM\(hyabort\fR
.sp 9p
.RT
.PP
If an application\(hyassociation exists, either the receiving or the sending
RTPM transfers an RTAB APDU to its peer as the User\(hydata parameter of
an A\(hyABORT request primitive. The RTPM issues a RT\(hyP\(hyABORT indication
primitive to its RTSE\(hyuser.
.RT
.sp 1P
.LP
7.9.2.3.2
\fIRTAB APDU\fR
.sp 9p
.RT
.PP
If the sending or the receiving RTPM receives an RTAB APDU as the User\(hydata
parameter of an A\(hyABORT indication primitive, it issues an RT\(hyP\(hyABORT
indication primitive to its RTSE\(hyuser.
.RT
.sp 1P
.LP
7.9.2.3.3
\fIRecovery time\(hyout\fR
.sp 9p
.RT
.PP
If an application\(hyassociation does not exist and a local recovery time\(hyout
occurs, the RTPM issues an RT\(hyP\(hyABORT indication primitive to its
RTSE\(hyuser.
.RT
.sp 1P
.LP
7.9.2.4
\fIUse of the RTAB APDU fields\fR
.sp 9p
.RT
.PP
The RTAB APDU fields are used as follows.
.RT
.sp 1P
.LP
7.9.2.4.1
\fIAbort\(hyreason\fR
.sp 9p
.RT
.PP
The value of this field is \*Qpermanent\(hyerror\*U.
.bp
.RT
.sp 1P
.LP
7.9.2.4.2
\fIReflected\(hyparameter\fR
.sp 9p
.RT
.PP
This field is not used.
.RT
.sp 1P
.LP
7.9.2.4.3
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This field is not used.
.RT
.sp 2P
.LP
7.9.3
\fIUser\(hyabort\fR
.sp 1P
.RT
.sp 1P
.LP
7.9.3.1
\fIPurpose\fR
.sp 9p
.RT
.PP
The user\(hyabort procedure is used by the requestor to abort an
application\(hyassociation.
.RT
.sp 1P
.LP
7.9.3.2
\fIAPDUs used\fR
.sp 9p
.RT
.PP
The user\(hyabort procedure uses the RT\(hyABORT (RTAB) APDU. The RTAB
APDU is specified in clause\ 7.7.3.2.
.RT
.sp 1P
.LP
7.9.3.3
\fIUser\(hyabort procedure\fR
.sp 9p
.RT
.PP
This procedure is driven by the following events:
.RT
.LP
a)
an RT\(hyU\(hyABORT request primitive from the requestor;
.LP
b)
an RTAB APDU as User\(hydata of an A\(hyABORT indication
primitive.
.sp 1P
.LP
7.9.3.3.1
\fIRT\(hyU\(hyABORT request\fR
.sp 9p
.RT
.PP
If the requesting RTPM receives an RT\(hyU\(hyABORT request primitive
from the requestor, an RTAB APDU is formed from the parameter value of the
RT\(hyU\(hyABORT request primitive and transferred as User\(hydata of an
A\(hyABORT request primitive.
.RT
.sp 1P
.LP
7.9.3.3.2
\fIRTAB APDU\fR
.sp 9p
.RT
.PP
If the accepting RTPM receives the RTAB APDU as User\(hydata of an
A\(hyABORT indication primitive, the accepting RTPM issues an RT\(hyU\(hyABORT
indication primitive to the acceptor. The RT\(hyU\(hyABORT primitive parameter
is
derived from the RTAB APDU.
.RT
.sp 1P
.LP
7.9.3.4
\fIUse of the RTAB APDU fields\fR
.sp 9p
.RT
.PP
The RTAB APDU fields are used as follows.
.RT
.sp 1P
.LP
7.9.3.4.1
\fIAbort\(hyreason\fR
.sp 9p
.RT
.PP
The value of this field is \*Quser\(hyerror\*U.
.RT
.sp 1P
.LP
7.9.3.4.2
\fIReflected\(hyparameter\fR
.sp 9p
.RT
.PP
This field is not used.
.RT
.sp 1P
.LP
7.9.3.4.3
\fIUser\(hydata\fR
.sp 9p
.RT
.PP
This is the User\(hydata parameter value of the RT\(hyU\(hyABORT request
primitive. It appears as the User\(hydata parameter value of the RT\(hyU\(hyABORT
indication primitive.
.RT
.sp 1P
.LP
7.10
\fIRules for extensibility\fR
.sp 9p
.RT
.PP
In addition to the procedures stated above the following rule also applies
when
processing APDUs defined in this Recommendation:
.RT
.LP
\(em
Ignore parameters which are not defined in this
Recommendation for RTORQ, RTOAC, and RTORJ APDUs.
.LP
.bp